Generating packets in a reverse direction of a service function chain

ABSTRACT

Embodiments are directed to receiving an original packet at a service function; determining, for a reverse packet, a reverse service path identifier for a previous hop on a service function chain; determining, for the reverse packet, a service index for the reverse service path identifier; and transmitting the reverse packet to the previous hop on the service function chain.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of priority under 25 U.S.C. § 119(2)to U.S. Provisional Application Ser. No. 62/328,474 entitled “GENERATINGPACKETS IN A REVERSE DIRECTION OF A SERVICE FUNCTION CHAIN” filed Apr.27, 2016, which is hereby incorporated by reference in its entirety.

FIELD

This disclosure pertains to service function chaining and generatingpackets in a reverse direction of a service function chain.

BACKGROUND

In computer networking, network administrators are often concerned withhow to best route traffic flows from one end point to another end pointacross a network. When provisioning a route for a traffic flow,administrators may implement policies to ensure that certain servicefunctions are applied to the packet or the traffic flow as it traversesacross the network. Service functions can provide security, wide areanetwork (WAN) acceleration, and load balancing. These service functionscan be implemented at various points in the network infrastructure, suchas the wide area network, data center, campus, etc. Network elementsproviding these service functions are generally referred to as “servicenodes.”

Traditionally, service node deployment is dictated by the networktopology. For instance, firewalls are usually deployed at the edge of anadministrative zone for filtering traffic leaving or entering theparticular zone according to a policy for that zone. With the rise ofvirtual platforms and more agile networks, service node deployment canno longer be bound by the network topology. To enable service nodes tobe deployed anywhere on a network, a solution called Service FunctionChaining (SFC) Architecture and Network Service Header (NSH) have beenprovided to encapsulated packets or frames to prescribe service pathsfor traffic flows through the appropriate service nodes. Specifically,Network Service Headers provide data plane encapsulation that utilizesthe network overlay topology used to deliver packets to the requisiteservices.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts.

FIG. 1A is a schematic block diagram of a Service Function Chain (SFC),which may include an initial Classification function, as an entry pointinto a Service Function Path (SFP), according to some embodiments of thedisclosure;

FIGS. 1B-C is a schematic block diagram of different service pathsrealized using service function chaining, according to some embodimentsof the disclosure;

FIG. 2 is a schematic block diagram of a system view of a Service ChainFunction-aware network element for prescribing a service path of atraffic flow, according to some embodiments of the disclosure;

FIG. 3 is a schematic block diagram of a system view of a service node,according to some embodiments of the disclosure;

FIG. 4 is a schematic diagram of a network service header in accordancewith embodiments of the present disclosure;

FIG. 5 is a schematic diagram of a network service header of a packetthat includes a reverse packet request bit field in accordance withembodiments of the present disclosure;

FIG. 6 is a process flow diagram for setting an OAM bit for reverse pathforwarding in accordance with embodiments of the present disclosure;

FIG. 7 is a process flow diagram for setting an reverse bit for reversepath forwarding in accordance with embodiments of the presentdisclosure;

FIG. 8 is a process flow diagram for a classifier to encode reverse pathinformation in accordance with embodiments of the present disclosure;

FIG. 9 is a process flow diagram for an orchestrator to calculatereverse path information in accordance with embodiments of the presentdisclosure;

FIG. 10 is another process flow diagram for an orchestrator to calculatereverse path information in accordance with embodiments of the presentdisclosure.

FIG. 11 is a process flow diagram for making symmetric an asymmetricforward and reverse service path in accordance with embodiments of thepresent disclosure.

DETAILED DESCRIPTION

This disclosure describes providing the ability for a service functionto generate a packet mid-service chain back to the source using a NSH.

Service Functions like Firewall, NAT, Proxies and Intrusion Detectiongenerate packets like ICMP Errors, TCP Resets and TCP SYN-ACK to thesource of the current in-process packet. This disclosure describesending return packets to a source in a service function chainenvironment.

In service chain environments, generated return packets traverse theservice path in the reverse order as that of the original packet. At theoutset, a set of requirements are met in order to allow a packet to makeits way back to its source through the service path:

a. A symmetric path-id is established;

b. At a minimum, the SF needs to be able encapsulate such error or proxypackets in an encapsulation transport, such as VXLAN-GPE+NSH header; and

c. The SF needs to be able to determine, directly or indirectly, thesymmetric path id and associated next service-hop index.

Basics of Network Service Chaining or Service Function Chains in aNetwork

To accommodate agile networking and flexible provisioning of networknodes in the network, Service Function Chains (SFC) can be used toensure an ordered set of Service Functions (SF) to be applied to packetsand/or frames of a traffic flow. SFCs provides a method for deployingSFs in a way that enables dynamic ordering and topological independenceof those SFs. A service function chain can define an ordered set ofservice functions that is applied to packets and/or frames of a trafficflow, where the ordered set of service functions are selected as aresult of classification. The implied order may not be a linearprogression as the architecture allows for nodes that copy to more thanone branch. The term service chain is often used as shorthand forservice function chain.

FIG. 1A illustrates a Service Function Chain (SFC), which may include aninitial service classification function 102, as an entry point into aService Function Path (SFP) 104 (or service path). The (initial) serviceclassification function 102 prescribes a service path, and encapsulatesa packet or frame with the service path information which identifies theservice path. The classification potentially adds metadata, or sharedcontext, to the SFC encapsulation part of the packet or frame. Theservice function path 104 may include a plurality of service functions(shown as “SF1”, . . . “SFN”), implemented or provided by one or moreservice nodes.

A service function can be responsible for specific treatment of receivedpackets. A service function can act at the network layer or other OSIlayers (e.g., application layer, presentation layer, session layer,transport layer, data link layer, and physical link layer). A servicefunction can be a virtual instance or be embedded in a physical networkelement such as a service node. When a service function or other modulesof a service node is executed by the at least one processors of theservice node, the service function or other modules can be configured toimplement any one of the methods described herein. Multiple servicefunctions can be embedded in the same network element. Multipleinstances of the service function can be enabled in the sameadministrative SFC-enabled domain. A non-exhaustive list of SFsincludes: firewalls, WAN and application acceleration, Deep PacketInspection (DPI), server load balancers (SLBs), NAT44, NAT64, HOST_IDinjection, HTTP Header Enrichment functions, TCP optimizer, applicationdelivery controllers (ADCs) etc. An SF may be SFC encapsulation aware,that is it receives, and acts on information in the SFC encapsulation,or unaware in which case data forwarded to the service does not containthe SFC encapsulation.

A Service Node (SN) can be a physical network element (or a virtualelement embedded on a physical network element) that hosts one or moreservice functions (SFs) and has one or more network locators associatedwith it for reachability and service delivery. In many standardizationdocuments, “service functions” can refer to the service nodes describedherein as having one or more service functions hosted thereon. ServiceFunction Path (SFP) (or sometimes referred simply as service path)relates to the instantiation of a SFC in the network. Packets follow aservice path from a classifier through the requisite service functions.

FIGS. 1B-C illustrate different service paths realized using servicefunction chaining. These service paths can be implemented byencapsulating packets of a traffic flow with a network service header(NSH) or some other suitable packet header which specifies a desiredservice path (e.g., by identifying a particular service path usingservice path information in the NSH). In the example shown in FIG. 1B, aservice path 120 can be provided between end point 160 and endpoint 180through service node 106 and service node 110. In the example shown inFIG. 1C, a service path 130 (a different instantiation) can be providedbetween end point 170 and endpoint 190 through service node 106, servicenode 108, and service node 112.

Network Service Header (NSH) Encapsulation

Generally speaking, an NSH includes service path information, which canidentify or prescribe a particular service path (an instance of aservice function chain), and NSH is added to a packet or frame. Forinstance, an NSH can include a data plane header added to packets orframes. Effectively, the NSH creates a service plane. The NSH includesinformation for service chaining, and in some cases, the NSH can includemetadata added and/or consumed by service nodes or service functions.The packets and NSH are encapsulated in an outer header for transport.To implement a service path, a network element such as a serviceclassifier (SCL) or some other suitable SFC-aware network element canprocess packets or frames of a traffic flow and performs NSHencapsulation according to a desired policy for the traffic flow.

FIG. 2 shows a system view of SFC-aware network element, e.g., such as a(initial) service classifier (SCL), for prescribing a service path of atraffic flow, according to some embodiments of the disclosure. Networkelement 202 includes processor 204, (computer-readable non-transitory)memory 206 for storing data and instructions. Furthermore, networkelement 202 includes service classification function 208 and serviceheader encapsulator 210 (both can be provided by processor 204 whenprocessor 204 executes the instructions stored in memory 206).

The service classification function 208 can process a packet of atraffic flow and determine whether the packet requires servicing andcorrespondingly which service path to follow to apply the appropriateservice. The determination can be performed based on business policiesand/or rules stored in memory 206. Once the determination of the servicepath is made, service header encapsulator 210 generates an appropriateNSH having identification information for the service path (“servicepath information”) and adds the NSH to the packet. The service headerencapsulator 210 provides an outer encapsulation to forward the packetto the start of the service path. Other SFC-aware network elements arethus able to process the NSH while other non-SFC-aware network elementswould simply forward the encapsulated packets as is. Besides insertingan NSH, network element 202 can also remove the NSH if the serviceclassification function 208 determines the packet does not requireservicing.

Network Service Headers

A network service header (NSH) can include a (e.g., 64-bit) base header,and one or more context headers. Generally speaking, the base headerprovides information about the service header and service pathidentification (e.g., a service path identifier), and context headerscan carry opaque metadata (such as the metadata described hereinreflecting the result of classification). For instance, an NSH caninclude a 4-byte base header, a 4-byte service path header, and optionalcontext headers. The base header can provide information about theservice header and the payload protocol. The service path header canprovide path identification and location within a path. The (variablelength) context headers can carry opaque metadata and variable lengthencoded information. The one or more optional context headers make up acontext header section in the NSH. For instance, the context headersection can include one or more context header fields having pieces ofinformation therein, describing the packet/frame.

The context header fields are particularly suitable for sharing contextinformation about a packet or frame as the packet or frame traverses theservice path. Based on the information in the base header, a servicefunction of a service node can derive policy selection from the NSH.Context headers shared in the NSH can provide a range ofservice-relevant information such as traffic classification. Servicefunctions can use NSH to select local service policy. A common usage isfor service functions to deny or permit certain types of traffic basedon the traffic classification in the context headers of the NSH.

Service Nodes and Proxy Nodes

Once properly encapsulated, the packet having the NSH is then forwardedto one or more service nodes where service(s) can be applied to thepacket/frame. FIG. 3 shows a system view of a service node, according tosome embodiments of the disclosure. Service node 300, generally anetwork element, can include processor 302, (computer-readablenon-transitory) memory 304 for storing data and instructions.Furthermore, service node 300 includes service function(s) 306 (e.g.,for applying service(s) to the packet/frame, classifying thepacket/frame) and service header processor 308. The service functions(s)306 and service header processor 306 can be provided by processor 302when processor 302 executes the instructions stored in memory 304.Service header processor 308 can extract the NSH, and in some cases,update the NSH as needed. For instance, the service header processor 308can decrement the service index if a service index=0 is used to indicatethat a packet is to be dropped by the service node 300. In anotherinstance, the service header processor 308 or some other suitable moduleprovide by the service node can update context header fields ifnew/updated context is available.

Aspects of service function chaining can be further found in InternetEngineering Task Force (IETF) publication Penno et al. “PacketGeneration in Service Function Chains”, available attools.ietf.org/html/draft-penno-sfc-packet-01, the contents of which arehereby incorporated by reference in their entirety.

When a Service Function (SF) wants to send packets to the reversedirection back to the source, the SF can use a reverse service path ID(such as a symmetric service path ID) and an associated service index.This symmetric service Path ID information is not normally available toSFs since SFs do not need to perform a next-hop service lookup. Thisdisclosure describes how the SF can identify a symmetric service path IDand corresponding associated service index:

In some embodiments, the SF can derive reverse service path forwardinginformation from an incoming packet.

In some embodiments, the SF can send the packet in the forward directionbut set appropriate bits in the network service header (NSH) requestinga SFF to send the packet back to the source.

In some embodiments, the classifier can encode all information the SFneeds to send a reverse packet in the metadata header.

In some embodiments, a controller uses a deterministic algorithm whencreating the associated symmetric path-id and index.

Embodiment 1

In a first embodiment, the SF can derive the reverse service pathforwarding information. The SF can be configured to receive and processa subset of the information from an incoming, original packet. When a SFwants to send a packet to the source, the SF uses information conveyedvia the control plane to impose the correct NSH values.

FIG. 4 is a process flow diagram 400 for a service function to usecontrol plane information to impose NSH values. The SF can receive apacket (402). A policy or other trigger can cause the SF to generate areverse packet (404). A reverse packet is one that traverses the sameservice functions as the original packet, but in a reverse direction.The controller can determine the reverse path ID from control planeinformation from the original packet (406). The controller can determinea reverse path index from control plane information (408). The SF canthen forward the packet to the reverse hop SF through the SFF (410). TheSFF can interpret the reverse path information for forwarding packets toanother service function.

Advantages of this embodiment include:

-   -   Changes are restricted to SF and controller, no changes to SFF;    -   Incremental deployment possible;    -   No protocol between SF and SFF, which avoids interoperability        issues; and    -   No performance penalty on SFF due to in or out-of-band protocol.

Embodiment 2

In some embodiments, the SF can set an OAM bit in the packet header.When the SF needs to send a packet in the reverse direction it will setthe OAM bit in the NSH header and use an OAM protocol[I-D.penno-sfc-trace] to request that the SFF impose a new, reverse-pathNSH. Post imposition, the SFF forwards the packet correctly. FIG. 5 is aschematic diagram of a network service header 500 of a packet thatincludes a reverse packet request bit field.

In an example embodiment, the following bit fields can be set by the SFto request a reverse packet:

OAM Bit: 1

Length: 6

MD-Type: 1

Next Protocol: OAM Protocol

Rev. Pkt Req: 1 Reverse packet request

FIG. 6 is a process flow diagram 600 for setting an OAM bit for reversepath forwarding. The SF can receive a packet and a reverse packet can betriggered based off a policy or other triggering event. The SF can setan operation, administration, and maintenance (OAM) bit in the reversepacket NSH (602). The OAM bit serves as an indication to the SFF to seta new reverse path based on other information encoded into the packetheader (604). The SFF can then forward the reverse packet to theappropriate reverse hop destination (606). The SFF examine itsforwarding tables and find the reverse path-id and index of the nextservice-hop. The reverse path can be found in the Rendered Service PathYang model that is conveyed to the SFF when a path is constructed.

If a SFF does not understand the OAM message it just forwards the packetbased on the original path-id and index. Since it is a special OAMpacket, it tells other SFFs and SFs that they should process itdifferently. For example, a downstream intrusion detection SF might notassociate flow state with this packet.

In some embodiments, the SF can set a reserved bit to trigger the SFF toidentify the reverse path and forward the packet. FIG. 7 is a processflow diagram 700 for setting a reverse bit for reverse path forwarding.In this embodiment, the SF sets a reversed bit in the NSH of the reversepacket (702). The reserve bit carries the same semantic information asin the OAM embodiment described with FIG. 6 above. The SFF can interpretthe reserve bit to be an instruction for the SFF to identify the reversepath and impose the reverse path on the reverse packet (704). The SFFcan then forward the reverse packet to the reverse next hop destination(706).

This embodiment involves allocating one of the reserved bits. Anotherissue is that the metadata in the original packet might be overwrittenby SFs or SFFs in the path.

In the embodiments described in FIGS. 6 and 7, when a SFF receives a NSHpacket with the reversed bit set, the SFF shall look up a preprogrammedtable to map the Service Path ID and Index in the NSH packet into thereverse Service Path ID and Index. The SFF would then use the newreverse ID and Index pair to determine the SF/SFF which is in thereverse direction.

Embodiment 3

The classifier can encode all information the SF needs to send a reversepacket in the metadata header. This embodiment allows the ServiceFunction to send a reverse packet without interactions with thecontroller or SFF. Also, the SF does not need to have the OAM bit set oruse a reserved bit. The penalty is that for a MD Type-1 packet, asignificant amount of information (48 bits) may be encoded in themetadata section of the packet and this data should not be overwritten.

Ideally this metadata would need to be added by the classifier. TheRendered Service Path yang model [RSPYang] provides the reverse servicepath information that a classifier would need to add to the metadataheader.

A classifier encodes the requisite reverse service path information—pathID and index—along the service path, allowing the Service Function tosend a reverse packet without interactions with the controller or SFF,therefore it is very attractive.

The Rendered Service Path yang model [RSPYang] already provides all thenecessary information that a classifier would need to add to themetadata header. An explanation of this method is better served with anexample. Below, JSON objects to two symmetric paths are illustrated:

RENDERED_SERVICE_PATH_RESP_JSON = ″″″  {   “rendered-service-paths”: {   “rendered-service-path”: [     {      “name”:“SFC1-SFP1-Path-2-Reverse”,      “transport-type”:“service-locator:vxlan-gpe”,      “parent-service-function-path”:“SFC1-SFP1”,      “path-id”: 3,      “service-chain-name”: “SFC1”,     “starting-index”: 255,      “rendered-service-path-hop”: [       {       “hop-number”: 0,        “service-index”: 255,“service-function-forwarder-locator”: “eth0”,       “service-function-name”: “SF3”,       “service-function-forwarder”: “SFF3”       },       {       “hop-number”: 1,        “service-index”: 254,       “service-function-forwarder-locator”: “eth0”,       “service-function-name”: “SF2”,       “service-function-forwarder”: “SFF2”       },       {       “hop-number”: 2,        “service-index”: 253,       “service-function-forwarder-locator”: “eth0”,       “service-function-name”: “SF1”,       “service-function-forwarder”: “SFF1”       }      ],     “symmetric-path-id”: 2     },         {          “name”:“SFC1-SFP1-Path-2”,          “transport-type”:“service-locator:vxlan-gpe”,          “parent-service-function-path”:“SFC1-SFP1”,          “path-id”: 2,          “service-chain-name”:“SFC1”,          “starting-index“: 253,         “rendered-service-path-hop”: [           {           “hop-number”: 0,            “service-index”: 253,           “service-function-forwarder-locator”: “eth0”,           “service-function-name”: “SF1”,           “service-function-forwarder”: ” SFF1”           },          {            “hop-number”: 1,            “service-index”: 252,           “service-function-forwarder-locator”: “eth0”,           “service-function-name”: “SF2”,           “service-function-forwarder”: ” SFF2”           },          {            “hop-number”: 2,            “service-index”: 251,           “service-function-forwarder-locator”: “eth0”,           “service-function-name”: “SF3”,     “service-function-forwarder”: “SFF3”           }           ],          “symmetric-path-id”: 3           }          ]         }       }″″″

The classifier can1 encode the following information in the metadata:

-   -   symmetric path-id=2 (24 bits)    -   symmetric starting index=253 (8 bits)    -   symmetric number of hops=3 (8 bits)    -   starting index=255 (8 bits)

In the method below, it is assumed that the SF will generate a reversepacket after decrementing the index of the current packet. Thedecremented index is referred to as the current index.

If SF1 wants to generate a reverse packet it can find the appropriateindex by applying the following algorithm:current_index=252remaining_hops=symmetric_number_hops−starting_index−current_indexremaining_hops=3−(255−252)=0reverse_service_index=symmetric_starting_index−remaining_hops−1reverse_service_index=next_service_hop_index=253−0−1=252

The “−1” is necessary for the service index to point to the nextservice_hop.

If SF2 wants to send reverse packet:current index=253remaining_hops=3−(255−253)=1reverse_service_index=next_service_hop_index=253−1−1=251

IF SF3 wants to send reverse packet:current index=254remaining_hops=3−(255−254)=2reverse_service_index=next_service_hop_index=253−2−1=250

The following tables summarize the service indexes as calculated by eachSF in the forward and reverse paths respectively.

Fwd SI=forward Service Index

Cur SI=Current Service Index

Gen SI=Service Index for Generated packets

RSFP1 Forward—

-   -   Number of Hops: 3    -   Forward Starting Index: 253    -   Reverse Starting Index: 255

SF SF1 SF2 SF3 Fwd SI 253 252 251 Cur SI 252 251 250 Gen SI 252 253 254

-   -   RSFP1 Reverse—    -   Number of Hops: 3    -   Reverse Starting Index: 255    -   Forward Starting Index: 253

SF SF1 SF2 SF3 Rev SI 253 254 255 Cur SI 252 253 254 Gen SI 252 251 250

Service indexes generated by each SF in the symmetric forward andreverse paths.

FIG. 8 is a process flow diagram 800 for a classifier to encode thereverse path information into a packet metadata. An original packet canbe received at a classifier of a service function chain (802). Theclassifier can encode the reverse path information into packet metadata(804). The reverse path information can include a rendered servicefunction path and/or a rendered reverse service path. The SF can thengenerate reverse packets using metadata extracted from packet metadata(806).

Embodiment 4

In some embodiments, the reverse path derived using Forward Path ID andIndexing. In this embodiment, no extra storage is required from the NSHand the mechanism is completely transparent to SFF. Reverse service pathis programmed directly by Orchestrator and used by SF interested insending upstream traffic.

Instead of defining a new Service Path ID, the same Service Path ID isused. The Orchestrator must define the reverse chain of servicefunctions using a different range of Service Path Index (SPI). It isalso assumed that the reverse packet must go through the same number ofServices as its forwarding path. It is proposed that Service Path Index0 . . . 127 and 255 . . . 128 is the exact mirror of each other.

Here is an example: SF1, SF2, and SF3 are identified using SPI 8, 7 and6 respectively.

Path 100 Index 8—SF1

Path 100 Index 7—SF2

Path 100 Index 6—SF3

Path 100 Index 5—Terminate

At the same time, Orchestrator then programs SPI 248, 249 and 250 asSF1, SF2 and SF3. Orchestrator also programs SPI 247 as “terminate”.Reverse−SPI=256−SPI.

Path 100 Index 247—Terminate

Path 100 Index 248 (256−8)—SF1

Path 100 Index 249 (256−7)—SF2

Path 100 Index 250 (256−6)—SF3

If SF3 needs to send the packet in reverse direction, it calculates thenew SPI as 256−6 (6 is the SPI of its received packet) and obtained 250.It then subtract the SPI by 1 and sends the packet back to SFF.Subsequently, SFF received the packet and sees the SPI 249. It thendiverts the packet to SF2, etc. Eventually, the packet SPI will drop to247 and the SFF will strip off the NSH and deliver the packet.

The same mechanism works even if SF1 later decided to send back anotherupstream packet. The packet can ping-pong between SF1 and SF3 using themechanism described above.

Some embodiments make use of a different Service Path ID, e.g. the mostsignificant bit. The bit can be flipped when the SF needs to send packetin reverse. However, the calculation of the reversed SPI is stillrequired, e.g. SPI 6 becomes SPI 121.

In either case, the SF must have the knowledge through Orchestrator thatthe reverse service path has been programmed and the method (SPI only orSPI+SPID bit) to use.

FIG. 9 is a process flow diagram 900 for calculating a reverse path fromforward path information in accordance with embodiments of the presentdisclosure. The SF can first identify a current index (902). The SFcalculates the reverse service hop index corresponding to its owncurrent index (904). The SF can decrement the reverse service hop indexfor itself to calculate the reverse hop destination SF (906). The SF canthen transmit the reverse packet to the SF associated with the reverseservice hop destination SF (908). The receiving SF can repeat thecalculations to identify the next reverse hop destination SF.

FIG. 10 is a process flow diagram 1000 for an orchestrator calculatingthe reverse path in accordance with embodiments of the presentdisclosure. The orchestrator can identify a reverse service path indexbased on a distinct range of available index values (1002). For example,the orchestrator can assign a new, distinct index value for each SF. TheSF can calculate its reverse service index using information from theorchestrator (1004). The SF can decrement the reverse service index tocalculate the reverse next hop SF destination (1006). The SF cantransmit the reverse packet to the reverse hop SF (1008).

Asymmetric Service Paths

In some embodiments, the forward and reverse paths can be asymmetric,comprising different set of SFs or SFs in different orders. The forwardpath can be composed of SF1→SF2→SF4→SF5, while the reverse path skipsSF5 and has SF3 in place of SF2 (e.g., SF4→SF3→SF1).

An asymmetric SFC can have completely independent forward and reversepaths. An SF's location in the forward path can be different from thatin the reverse path. An SF may appear only in the forward path but notreverse (and vice-versa). In order to use the same algorithm tocalculate the service index generated by an SF, one design option is toinsert special NOP SFs in the rendered service paths so that each SF ispositioned symmetrically in the forward and reverse rendered paths. TheSFP corresponding to the example above is:

SFP1 Forward→SF1:SF2:NOP:SF4:SF5

SFP2 Reverse←SF1:NOP:SF3:SF4:NOP

The NOP SF is assigned with a sequential service index the same way as aregular SF. The SFF receiving a packet with the service path ID andservice index corresponding to a NOP SF should advance the service indextill the service index points to a regular SF.

In some implementations, the controller can use a loopback interface orother methods on the SFF to skip the NOP SFs.

Once the NOP SF is inserted in the rendered service paths, the forwardand reverse paths become symmetric. The same algorithm can be applied bythe SFs to generate service indexes in the opposite directional path.The following tables list example service indexes corresponding to theexample above.

Fwd SI=forward Service Index

Cur SI=Current Service Index

Gen SI=Service Index for Generated packets

-   -   RSP1 Forward—        -   Number of hops: 5        -   Forward Starting Index: 250        -   Reverse Starting Index: 255

SF SF1 SF2 NOP SF4 SF5 Fwd SI 250 249 248 247 246 Cur SI 249 248 247 246245 Gen SI 250 251 N/A 253 254

-   -   RSP1 Reverse—        -   Number of hops: 5        -   Reverse Starting Index: 255        -   Forward Starting Index: 250

SF SF1 SF2 NOP SF4 SF5 Rev SI 251 252 253 254 255 Cur SI 250 251 252 253254 Gen SI 249 N/A 247 246 N/A

This symmetrization of asymmetric paths could be performed by acontroller during path creation.

FIG. 11 is a process flow diagram for making symmetric an asymmetricforward and reverse service path in accordance with embodiments of thepresent disclosure. A service function path for a forward direction canbe identified (1102). A service function path for a forward directioncan be identified (1104). The differences in service functions betweenforward path and reverse path can be determined (1106). That is, the SFsthat are missing from the forward service path, but that are present inthe reverse path, can be identified. Similarly, the SFs that are missingfrom the reverse service path, but that are present in the forward path,can be identified. A NOP (placeholder SF) can be inserted for missingSFs in forward service function path (1108). A NOP (placeholder SF) canbe inserted for missing SFs in revere service function path (1110). Adiscrete set of service indices can be mapped to each SF in forwardpath, including NOP (1112). A discrete set of service indices can bemapped to each SF in reverse path, including NOP (1114). The forward andreverse_service paths can be rendered (1116) and the packet forwarded.The packet is forwarded through the service chain, and when a NOP isreached, the service_index is decremented and the packet forwarded tothe next non-NOP SF (1118).

Metadata

A crucial consideration when generating a packet is which metadatashould be included in the context headers. In some scenarios if themetadata is not present the packet will not reach its intendeddestination. Although one could think of many different ways to conveythis information, the techniques should require little or no new ServiceFunction functionality.

It is assumed that a Service Function normally needs to know thesemantics of the context headers in order to perform its functions. Butclearly knowing the semantics of the metadata is not enough. The issueis that although the SF knows the semantics of the metadata when itreceives a packet, it might not be able to generate or retrieve thecorrect metadata values to insert in the context headers when generatinga packet. It is usually the classifier that insert the metadata in thecontext headers.

This disclosure describes service-path-invariant metadata. This ismetadata that is the same for all packets traversing a certain path. Forexample, if all packets exiting a service-path need to be routed to acertain VPN, the VPN ID would be a path-invariant metadata. Since thecontroller needs to send the semantics of the metadata present in thecontext headers to each Service Function, it is straightforward to sendalong the values of the path-invariant metadata. Therefore when theService Function generates a packet in can insert the minimum requiredmetadata for a packet to reach its destination.

There is a second type of metadata that the Service Function can providethe appropriate values, the one that it would be responsible forinserting anyway as part of packet processing.

Finally if the packet needs crucial metadata values that cannot besupplied by the two methods above then a reclassification is needed.This reclassification would need to be done by the classifier that wouldnormally process packets in the reverse path or a SFF that had the samerules and capabilities. Ideally the first SFF that processes thegenerated packet.

Embodiments of the present disclosure, for example, are described abovewith reference to block diagrams and/or operational illustrations ofmethods, systems, and computer program products according to embodimentsof this disclosure. The functions/acts noted in the blocks may occur outof the order as shown in any flowchart. For example, two blocks shown insuccession may in fact be executed substantially concurrently or theblocks may sometimes be executed in the reverse order, depending uponthe functionality/acts involved.

While certain embodiments of the disclosure have been described, otherembodiments may exist. Furthermore, although embodiments of the presentdisclosure have been described as being associated with data stored inmemory and other storage mediums, data can also be stored on or readfrom other types of computer-readable media, such as secondary storagedevices, like hard disks, floppy disks, or a CD-ROM, a carrier wave fromthe Internet, or other forms of RAM or ROM. Further, the disclosedmethods' stages may be modified in any manner, including by reorderingstages and/or inserting or deleting stages, without departing from thedisclosure.

All rights including copyrights in the code included herein are vestedin and are the property of the Applicant. The Applicant retains andreserves all rights in the code included herein, and grants permissionto reproduce the material only in connection with reproduction of thegranted patent and for no other purpose.

While the specification includes examples, the disclosure's scope isindicated by the following claims. Furthermore, while the specificationhas been described in language specific to structural features and/ormethodological acts, the claims are not limited to the features or actsdescribed above. Rather, the specific features and acts described aboveare disclosed as examples for embodiments of the disclosure.

What is claimed is:
 1. A method comprising: receiving an original packetat a service function of a service function chain, the service functionchain comprising a plurality of service functions forming a servicefunction path in a forward direction; determining, for a reverse packet,a reverse service path identifier for a return service path for thereverse packet that is in a reverse direction from the service functionpath; determining, for the reverse packet, a service index for aprevious hop on the service function chain from the service function,wherein the previous hop is one of the plurality of service functions ofthe service function chain; and transmitting the reverse packet to theprevious hop on the service function chain along the return servicepath.
 2. The method of claim 1, wherein determining the reverse servicepath identifier comprises receiving the reverse service path identifierfrom a service function forwarder.
 3. The method of claim 1, furthercomprising identifying, from the original packet, service pathidentification information from metadata included in the originalpacket.
 4. The method of claim 1, wherein the original packet comprisesmetadata that comprises the reverse service path identifier; and whereindetermining the reverse service path identifier comprises identifyingthe reverse service path identifier from the metadata of the originalpacket.
 5. The method of claim 1, wherein determining the reverseservice path comprises: identifying a service path index from metadatain the original packet; and calculating a reverse service path indexbased on the service path index from the metadata in the originalpacket.
 6. The method of claim 5, wherein calculating the reverseservice path index based on the service path index from the originalpacket comprises: identifying a service index for a service functionassociated with the service path index; assigning a new distinct indexvalue to the service function, the new distinct index value correlatingto a same service function as the service function associated with theservice index; and calculating the reverse service path index using thenew distinct index values for each service function in the service pathindex from the original packet.
 7. The method of claim 1, whereindetermining the service index for the previous hop on the servicefunction chain from the service function comprises: determining a numberof remaining hops to a source of the original packet; and decrementing astarting index included in metadata of the original packet by one andthe number of remaining hops to calculate the service index for theprevious hop.
 8. The method of claim 7, wherein the number of remaininghops is determined based on a current index of the service function, thestarting index, and a symmetric number of hops included in the metadataof the original packet.
 9. A computer-readable non-transitory mediumcomprising one or more instructions for forwarding a packet in a reversedirection, that when executed on a processor configure the processor to:receive an original packet at a service function of a service functionchain, the service function chain comprising a plurality of servicefunctions forming a service function path in a forward direction;determine, for a reverse packet, a reverse service path identifier for areturn service path for the reverse packet that is in a reversedirection from the service function path; determine, for the reversepacket, a service index for a previous hop on the service function chainfrom the service function, wherein the previous hop is one of theplurality of service functions of the service function chain; andtransmit the reverse packet to the previous hop on the service functionchain along the return service path.
 10. The computer-readablenon-transitory medium of claim 9, wherein determining the reverseservice path identifier comprises receiving the reverse service pathidentifier from a service function forwarder.
 11. The computer-readablenon-transitory medium of claim 9, further comprising identifying, fromthe original packet, service path identification information frommetadata included in the original packet.
 12. The computer-readablenon-transitory medium of claim 9, wherein the original packet comprisesmetadata that comprises the reverse service path identifier; and whereindetermining the reverse service path identifier comprises identifyingthe reverse service path identifier from the metadata of the originalpacket.
 13. The computer-readable non-transitory medium of claim 9,wherein determining the reverse service path comprises: identifying aservice path index from metadata in the original packet; and calculatinga reverse service path index based on the service path index from themetadata in the original packet.
 14. The computer-readablenon-transitory medium of claim 13, wherein calculating the reverseservice path index based on the service path index from the originalpacket comprises: identifying a service index for a service functionassociated with the service path index; assigning a new distinct indexvalue to the service function, the new distinct index value correlatingto a same service function as the service function associated with theservice index; and calculating the reverse service path index using thenew distinct index values for each service function in the service pathindex from the original packet.
 15. The computer-readable non-transitorymedium of claim 9, wherein the instructions that, when executed by theprocessor to determine the service index for the previous hop on theservice function chain from the service function comprise instructionsthat cause the processor to: determine a number of remaining hops to asource of the original packet; and decrement a starting index includedin metadata of the original packet by one and the number of remaininghops to calculate the service index for the previous hop.
 16. Anorchestrator network element comprising: at least one memory elementhaving instructions stored thereon; at least one processor coupled tothe at least one memory element and configured to execute theinstructions to cause the orchestrator network element to: receive anoriginal packet at a service function of a service function chain, theservice function chain comprising a plurality of service functionsforming a service function path in a forward direction; determine, for areverse packet, a reverse service path identifier for a return servicepath for the reverse packet that is in a reverse direction from theservice function path; determine, for the reverse packet, a serviceindex for a previous hop on the service function chain from the servicefunction, wherein the previous hop is one of the plurality of servicefunctions of the service function chain; and transmit the reverse packetto the previous hop on the service function chain along the returnservice path.
 17. The orchestrator network element of claim 16, whereinthe at least one processor is configured to determine the service indexfor the previous hop on the service function chain from the servicefunction by: determining a number of remaining hops to a source of theoriginal packet; and decrementing a starting index included in metadataof the original packet by one and the number of remaining hops tocalculate the service index for the previous hop.
 18. The orchestratornetwork element of claim 16, wherein determining the reverse servicepath identifier comprises receiving the reverse service path identifierfrom a service function forwarder.
 19. The orchestrator network elementof claim 16, further comprising identifying, from the original packet,service path identification information from metadata included in theoriginal packet.
 20. The orchestrator network element of claim 16,wherein the original packet comprises metadata that comprises thereverse service path identifier; and wherein determining the reverseservice path identifier comprises identifying the reverse service pathidentifier from the metadata of the original packet.
 21. Theorchestrator network element of claim 16, wherein determining thereverse service path comprises: identifying a service path index frommetadata in the original packet; and calculating a reverse service pathindex based on the service path index from the metadata in the originalpacket.
 22. The orchestrator network element of claim 21, whereincalculating the reverse service path index based on the service pathindex from the original packet comprises: identifying a service indexfor a service function associated with the service path index; assigninga new distinct index value to the service function, the new distinctindex value correlating to a same service function as the servicefunction associated with the service index; and calculating the reverseservice path index using the new distinct index values for each servicefunction in the service path index from the original packet.